REMARKS 



In the Advisory Action, Claims 1-28 were examined and are rejected. In response to the 
Advisory Action, Claims 1, 6, 1 1 and 21 are amended, Claims 2, 6, and 28 are cancelled and no 
claims are added. Applicants respectfully request reconsideration of pending Claims 1-3, 4, 5, 
and 7-27 in view of the following remarks. 

I. Claims Rejected Under 35 U.S.C. §103(a) 

The Examiner has rejected Claims 1-4, 6-9, 11-13, 18-22 and 27-28 under 35 U.S.C. 
§ 103(a) as being unpatentable over U.S. Patent No 4,949,280 to Littlefield (" Littlefield ") in view 
of U.S. Patent No. 6,891,893 to Sullivan et al. (" Sullivan ".) Applicants respectfully traverse this 
rejection. 

Regarding Claim 1, Claim 1 recites the following claim features, which are neither taught 
nor suggested by the prior art combination of Littlefield in view of Sullivan : 

enabling a hardware accelerator selected from a plurality of hardware 
accelerators in response to at least one bit of a register within the register file 
that is set by a processing element when the processing element desires 
ownership of the selected hardware accelerator; and 

granting the processing element ownership over the selected hardware 
accelerator . (Emphasis added.) 

While Applicant's argument here is directed to the cited combination of references, it is 
necessary to first consider their individual teachings, in order to ascertain what combination (if 
any) could be made from the cited references. Littlefield is generally directed to a parallel 
processor based raster graphic system architecture. To provide the system architecture referred to 
bv Littlefield , (Col. 3, lines 41-48), Littlefield discloses an interconnection network (col. 4, lines 
21-28) that is illustrated with reference to Fig 3. 

Although Littlefield discloses that second interconnection network 18 may be used to 
connect each processor 29 within host 28 with any of the graphic processors 12, as taught by 
Littlefield , in the simplest case, such interface can be eliminated and each application processor 
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29 within the host 28 is paired with a graphics processor 12. (Col. 7, lines 19-28.) We submit 
that application processors 29 of host application 28, as shown in FIG. 5, do not set a bit of a 
register to receive ownership of a specific one of the graphic processors (GP) 12, as in Claim 1. 
We submit that Littlefield is silent as to how an application processor 29 is paired with a GP 12. 

According to the Examiner, FIG. 7 shows a detailed internal block diagram of the routing 
node 22 in the interconnection network and according to the Examiner, states "leading bits of the 
data stored in each register 38 and 40 are evaluated by associated routing determination logic 46, 
47 to generate XFR PORT OUT to the next node," (col. 8, lines 40-60). (See pg. 6, para. 1 of the 
Office Action mailed 5/31/07). 

We submit that the leading bits of the data stored in each register 38 and 40, as referred to 
by the Examiner, are the packet address bits that are read by routing arbitration logic 45 which 
controls the routing of data through multiplexers 42 and 44 (see col. 8, lines 48-51.) However, as 
explicitly disclosed by Littlefield , the network 18 comprises of packet switching network having 
three levels of network nodes, such that packets containing destination addresses and 
corresponding data are prepared by the graphics processor and sent into the network 18 along 
input data paths; at each node 22 within the network, the address field of a packet is examined to 
determine the routing to the appropriate memory location in the frame buffer 14. (See col. 6, 
lines 29-39.) 

We submit that the output port selection referred to by the Examiner and illustrated in 
FIG. 7 of Littlefield refers to a routing of packets between a graphics processor 12 and a memory 
location in frame buffer 14. We submit that the Examiner's characterization of Littlefield 
regarding the selection of a graphics processor 12 by an application processor 29 is not described 
with reference to col. 8, lines 40-60 or any other disclosure in Littlefield since the packet address 
bits referred to by the Examiner refer to a memory location in frame buffer 14 and not a GP 12 to 
enable selection of such GP 12 by an application processor 29, as in Claim 1. Hence, neither the 
sections referred to by the Examiner nor any other disclosure in Littlefield teaches or suggests 
enabling of a hardware accelerator selected from a plurality of hardware accelerators in response 
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to at least one bit of a register within a register file that is set by processing element when the 
processing element desires ownership of the selected hardware accelerator and the granting the 
processing element ownership over the selected hardware accelerator, as in Claim 1. 

In view of the above, assuming each application processes 29 of host 28 can connect with 
any graphics processors 12 shown in FIG. 5, Littlefield fails to teach how an application 
processor 29 selects the respective graphics processor GP 12, as in Claim 1. Hence, the 
capability disclosed by Littlefield to enable connection between any AP 29 and any GP 12 via 
interconnection network 18 neither discloses, teaches or suggests enabling a hardware accelerator 
from a plurality of hardware accelerators in response to at least one bit of register within the 
register file that is set by a processing element when the processing element desires ownership of 
the selected hardware accelerator, as in Claim 1 . As a result, the Examiner cites Sullivan . 

Sullivan discloses API 104 which identifies the operational capabilities of the multimedia 
processing system elements and selectively negotiates the processing of received multimedia 
content among these elements to improve multimedia processing performance. (See, Col. 8, 
lines 8-14.) Hence, API 104 facilitates the interoperability of any decoder application (160(A) - 
160(N)) with any multimedia accelerator (174(A) - 174(N)) (see, Col. 8, lines 15-17). 

In contrast with Claim 1, the process of finding a multimedia accelerator 174 that agrees 
to a decoding acceleration capability that is specified by the decoder (see Sullivan , Col. 27, lines 
39-42) does not teach or suggest enabling a hardware accelerator in response to a bit within a 
register file that is set by a processing element to select a hardware accelerator when the 
processing element desires ownership of the selected hardware accelerator much less the granting 
of a processing element ownership over the selected hardware accelerator, as in Claim 1 . In 
contrast with the selection of a hardware accelerator by a processing element, Sullivan teaches 
that the media processing element (e.g., decoder 160) iteratively issues configuration commands 
until a response is received from one of the multimedia accelerators (174(A) - 174(N)) to an 
issued auto-negotiation data structure 202 to indicate that the multimedia accelerator supports the 
media processing format defined in the auto-negotiation data structure 202. (See, col. 27, lines 
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39-42 and lines 51-56.) Apposite to Claim 1 , Sullivan teaches that the multimedia acceleration 
174(A) - 174(N) (hardware accelerator) selects the decoder 160 (processing element) when the 
processing element desires ownership of the selected hardware accelerator. 

We submit that the disclosure of Sullivan is limited to acceptance, by a multimedia 
accelerator 174, of a proposed media processing format defined in an auto-negotiation data 
structure issued by a decoder application 160. (See, supra.) Hence, we submit that the decoder 
160 (processing element), as disclosed by Sullivan, cannot select an accelerator 174 and therefore 
fails to teach or suggest the setting of at least one bit of a register within a register file to select a 
multimedia accelerator (processing element), as in Claim 1 . 

Apposite to Claim 1, Sullivan teaches that the processing element (e.g., decoder 160) 
repeatedly issues requests until a multimedia accelerator 174 issues a response that the 
accelerator 174 supports a proposed media processing format defined in an auto-negotiation data 
structure. Namely Sullivan teaches that the decoder application 160 is limited to use of the 
multimedia accelerator 174 that issues a response that a proposed media processing format to 
find in the anto-negotiation data structure is supported. In other words, assuming, arguendo, that 
the decoder application 160 desired ownership over a hardware accelerator, such as an 
accelerator 174, a negative response to an auto-negotiation data structure, issued by decoder 
application 160, would prohibit such ownership, in contrast to Claim 1. Hence, the combination 
of Littlefield in view of Sullivan would not allow an application processor to gain ownership 
over a selected hardware accelerator (graphics processor 12) since Sullivan fails to teach or 
suggest that a processing element, such as decoder 160, can select a multimedia accelerator 174 
in response to at least one bit of a register within the register file that is set by a processing 
element when the processing element desires ownership of the selected hardware accelerator, as 
in Claim 1 . 

Hence, no combination of Littlefield in view of Sullivan could teach or suggest the 
enabling of a hardware accelerator in response to at least one bit of a register file set by a 
processing element when the processing element desires ownership of the selected hardware 
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accelerator much less the granting of the processing element ownership over the selected 
hardware accelerator, as in Claim 1 . 

For each of the above reasons, therefore, Claim 1 and all claims which depend from 
Claim 1 are patentable over the prior art combination of Littlefield in view of Sullivan . 

Each of Applicants' other independent claims includes limitations similar to those in 
Claim 1 discussed above. Therefore, all of Applicants' other independent claims, and all claims 
which depend on them, are also patentable over the cited art, for similar reasons. Consequently, 
we request that the Examiner reconsider and withdraw the § 103(a) rejection of Claims 1-4, 6-9, 
11-13, 18-22, and 27-28. 

DEPENDENT CLAIMS 

Claims 5, 10, 14-17, 23-26 are rejected under 35 U.S.C. § 103(a) as being unpatentable 
over Littlefield in view of Sullivan and further in view of U.S. Patent No. 5,940,086 to 
Rentschler et al. (" Rentschler "). Applicants respectfully traverse this rejection. 

In view of the above remarks, a specific discussion of the dependent claims is considered 
to be unnecessary. Therefore, Applicants' silence regarding any dependent claim is not to be 
interpreted as an agreement with, or acquiescence to, the rejection of such claim or as waiving 
any argument regarding that claim. 
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CONCLUSION 



In view of the foregoing, it is believed that all claims now pending (1) are in proper form, 
(2) are neither obvious nor anticipated by the relied upon art of record, and (3) are in condition 
for allowance. A Notice of Allowance is earnestly solicited at the earliest possible date. If the 
Examiner believes that a telephone conference would be useful in moving the application 
forward to allowance, the Examiner is encouraged to contact the undersigned at (310) 207-3800. 

If necessary, the Commissioner is hereby authorized in this, concurrent and future replies, 
to charge payment or credit any overpayment to Deposit Account No. 02-2666 for any additional 
fees required under 37 C.F.R. §§ 1.16 or 1.17, particularly, extension of time fees. 



Respectfully submitted, 



BLAKELY, SOKOLOFF, TAYLOR, & ZAFMAN LLP 



Dated: 



By: 




Telephone (310) 207-3800 
Facsimile (408) 720-8383 



1279 Oakmead Parkway 
Sunnyvale, California 94085-4040 
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